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1. Introduction 


Router Requirements [1] specifies that routers must receive and 
forward directed broadcasts. It also specifies that routers MUST have 
an option to disable this feature, and that this option MUST default 
to permit the receiving and forwarding of directed broadcasts. While 
directed broadcasts have uses, their use on the Internet backbone 
appears to be comprised entirely of malicious attacks on other 
networks. 


Changing the required default for routers would help ensure new 
routers connected to the Internet do not add to the problems already 
present. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119. 


2. Discussion 


Damaging denial of service attacks led to the writing of [2] on 
Ingress Filtering. Many network providers and corporate networks have 
endorsed the use of these methods to ensure their networks are not 
the source of such attacks. 


A recent trend in Smurf Attacks [3] is to target networks which 


permit directed broadcasts from outside their networks. By permitting 
directed broadcasts, these systems become "Smurf Amplifiers." 
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While the continued implementation of ingress filters remains the 
best way to limit these attacks, restricting directed broadcasts 
should also receive priority. 


Network service providers and corporate network operators are urged 
to ensure their networks are not susceptible to directed broadcast 
packets originating outside their networks. 


Mobile IP [4] had provisions for using directed broadcasts ina 
mobile node’s use of dynamic agent discovery. While some 
implementations support this feature, it is unclear whether it is 
useful. Other methods of achieving the same result are documented in 
[5]. It may be worthwhile to consider removing the language on using 
directed broadcasts as Mobile IP progresses on the standards track. 


3. Recommendation 
Router Requirements [1] is updated as follows: 
Section 4.2.2.11 (d) is replaced with: 
(d) { <Network-prefix>, -1 } 


Directed Broadcast - a broadcast directed to the specified network 
prefix. It MUST NOT be used as a source address. A router MAY 
originate Network Directed Broadcast packets. A router MAY have a 
configuration option to allow it to receive directed broadcast 
packets, however this option MUST be disabled by default, and thus 
the router MUST NOT receive Network Directed Broadcast packets 
unless specifically configured by the end user. 


Section 5.3.5.2, second paragraph replaced with: 
A router MAY have an option to enable receiving network-prefix-— 
directed broadcasts on an interface and MAY have an option to 
enable forwarding network-prefix-directed broadcasts. These 
options MUST default to blocking receipt and blocking forwarding 
of network-prefix-directed broadcasts. 


4. Security Considerations 


The goal of this document is to reduce the efficacy of certain types 
of denial of service attacks. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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